Mach-II oder Fusebox 4.1 für Coldfusion MX

Frameworks können dabei helfen, dass sich bewährte Entwicklungspraktiken und Standards als eine solide Basis der Anwendungsentwicklung durchsetzen. In der Coldfusion-Welt haben sich inzwischen zwei Frameworks als Favoriten herauskristallisiert: Fusebox und Mach-II. In diesem Artikel sollen diese beiden kostenlosen Frameworks vorgestellt und verglichen werden. Außerdem sollen Argumente geliefert werden, die bei der Entscheidung für oder gegen das eine oder andere Framework helfen können.

Fusebox 4.1

Das Fusebox-Framework gibt es bereits seit mehr als sechs Jahren. Es war eines der ersten Frameworks für Coldfusion und ist inzwischen das beliebteste Standard-Framework in der Coldfusion-Welt. Fusebox 4.1 kam im Januar 2005 heraus und ist die bislang leistungsfähigste Version dieses Frameworks.

Wenn die Benutzer eine Fusebox-Anwendung aufrufen, übergeben sie dieser einen „action“-Wert, üblicherweise „fuseaction“ genannt. Je nach dieser spezifizierten fuseaction führt die Anwendung den entsprechenden Code zur Erfüllung der Anfrage aus.

Fusebox-Entwickler schreiben XML, um dem Framework mitzuteilen, wie es auf unterschiedliche fuseactions reagieren soll. Sie verwenden auch XML, um Einstellungen auf Anwendungsebene vorzunehmen, wie zum Beispiel die Zeichenkodierung, Vorlagen zur Fehlerbehandlung oder „Circuit“-Aliases. Circuits sind Unterelemente einer Fusebox-Anwendung, welche für kleinere und kohärentere Gruppen von fuseaction-Handlern sorgen.

Entwickler greifen auf einen Satz von „core files“ zurück, welche das Fusebox-Framework implementieren. Diese Core Files kümmern sich um alle Low-Level-Vorgänge, richten Speicherstrukturen ein, lesen und parsen die XML-Dateien.

Fusebox ist ein prozedurales Framework. Das bedeutet, dass die Core Files selber prozedural geschrieben sind. Auf die gleiche Weise sind die von Fusebox verwendeten fuseaction-Handler prozedural. Die Ausführung einer fuseaction erfolgt „von oben nach unten“, wie im XML-Code vom Entwickler festgelegt. So kann das XML zum Beispiel vorgeben, dass zur Ausführung einer bestimmten fuseaction zwei Coldfusion-Vorlagen eingebunden und in einer festgelegten Reihenfolge ausgeführt werden müssen.

Der Vorteil dieses vordefinierten Verhaltens ist, dass die Core Files die im XML definierten Aktionen zu einer einzigen Datei „kompilieren“, welche jede fuseaction ausführt. Dies führt zu einer sehr schnellen Performance, denn sobald die „Kompilierung“ durchgeführt wurde, überspringen alle weiteren Anfragen diesen Schritt und führen die „kompilierte“ fuseaction-Datei direkt aus.

Das Fusebox-Framework ermöglicht den Einsatz von Plugins, das sind Codedateien, welche so eingerichtet sind, dass sie an bestimmten Punkten während der Bearbeitung einer Anfrage ausgeführt werden. Plugins sind eine Möglichkeit zur Erweiterung des Funktionsumfangs des Fusebox-Frameworks, ohne die Core Files verändern zu müssen. Sie sind nützlich für Dinge wie Fehlerbehandlung, verschachtelte Layouts oder Sicherheitsfunktionen.

Fusebox 4.1 bietet jetzt auch Unterstützung für Coldfusion Components (CFCs). CFCs sind objektartige Konstruktionen, welche viele der Vorteile objektorientierter Programmierung auch für CF-Entwickler bieten. Damit ist es jetzt möglich, Methoden von CFCs über XML-Dateien zu instanziieren und aufzurufen. CFCs können dabei innerhalb einer Fusebox-Anwendung an einzelnen Stellen zum Einsatz kommen oder als komplett objektorientierte Modellebene, erforderlich sind sie aber nicht. Es ist durchaus möglich, eine Fusebox-Anwendung zu schreiben, die überhaupt keine CFCs benutzt.